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METHODS AND APPARATUS FOR PROVIDING NETWORKED 



CRYPTOGRAPHIC DEVICES RESILIENT TO CAPTURE 



Cross Reference to Related Applications 

This application claims priority to the U.S. provisional patent application identified by 
5 Serial No. 60/267,258, filed on February 8, 2001, and entitled "Networked Cryptographic 
Devices Resilient to Capture;" and to the U.S. provisional patent application identified by Serial 
No. 60/274,762, filed on March 9, 2001, and entitled "Networked Cryptographic Devices 
Resilient to Capture," the disclosures of which are incorporated by reference herein. 

Field of the Invention 

Mb 10 The present invention relates to cryptography and, more particularly, to techniques for 

g providing networked cryptographic devices which are resilient to capture. 

Background of the Invention 

A computing device that performs cryptographic signatures and/or decryptions using the 
=_ 15 private key of a public key pair, and that stores the private key locally on stable storage, is 
py typically vulnerable to exposure of that private key if the device is captured. While encryption 
jj-j of the private key under a password is common, the ease with which passwords succumb to 
O offline dictionary attacks implies that better protections are needed. Many such protections have 
been proposed, but most require tamper-resistance of the device. Others used in practice replace 
20 the password with a stronger key stored on another device that the user holds, thus moving the 
burden of protection to that device. Some of these existing approaches will now be discussed. 

One existing approach proposes methods to encrypt aDS A (Digital Signature Algorithm) 
or RSA (Rivest- Shamir- Adleman) private key using a password so that guesses at the password 
cannot be verified by an attacker who captures the device holding that private key, see, e.g., D.N. 
25 Hoover et al, "Software Smart Cards via Cryptographic Camouflage,"l 999 IEEE Symposium 
on Security and Privacy, pp. 208-215, May 1999, the disclosure of which is incorporated by 
reference herein. However, this feature comes at a severe price. For example, the device's 
public key must be kept secret, even from the device itself. Obviously, this is because when the 
attacker learns the public key, he can then verify a successfully decrypted private key. So, the 



public key must be hidden from all but a few trusted servers that verify signatures produced by 
the device or encrypt messages for the device. Also, with this approach, it is essential that no 
verifiable plaintext be encrypted, since this, too, could be used to verify guesses at the password. 
However, these are awkward constraints to be imposed on a cryptographic system. 
5 Another existing approach proposes simply not storing the device's private key on the 

device, but rather having the device download the private key from the server when needed, see, 
e.g., R. Perlman et al, "Secure Password-based Protocol for Downloading a Private Key," 
Proceedings of the 1999 Network and Distributed System Security Symposium, Feb. 1999, the 
disclosure of which is incorporated by reference herein. In this approach, to ensure that the 

1 0 private key is downloaded only to the user' s device, the device first proves it has been given the 
user's password. For this purpose there are numerous published protocols by which the device 
can authenticate to and exchange a key with a server using a password input by its user, without 
exposing that password to offline dictionary attacks. 

Some of these protocols require the device to already have a public key for the server, 

15 see, e.g., T.M.A. Lomas et al, "Reducing Risks from Poorly Chosen Keys," ACM Operating 
Systems Review, 23(5):14-18, Dec. 1989; S. Halevi et al., "Public-key Cryptography and 
Password Protocols," ACM Conference on Computer and Communications Security, pp. 
122-131, 1998; W. Fordet al., "Server-assisted Generation of a Strong Secret from a Password," 
IEEE International Workshop on Enterprise Security, 2000, the disclosures of which are 

20 incorporated by reference herein. 

Some of these protocols do not require the device to already have a public key for the 
server, see, e.g., S. M. Bellovin et al., "Encrypted Key Exchange: Password-based Protocols 
Secure Against Dictionary Attacks," 1 992 IEEE Symposium on Security and Privacy, pp . 72-84, 
1992; D. Jablon, "Strong Password-only Authenticated Key Exchange,"ACM Computer 

25 Communication Review 26(5):5-20, 1996, T. Wu, "The Secure Remote Password Protocol," 
1998 Network and Distributed System Security Symposium, Feb. 1999; M. Bellare et al., 
"Authenticated Key Exchange Secure Against Dictionary Attacks," Advances in Cryptology - 
EUROCRYPT 2000, Lecture Notes in Computer Science 1807, pp. 139-155, 2000; V. Boyko 
et al., "Provably Secure Password Authentication and Key Exchange Using Diffie-Hellman," 

30 Advances in Cryptology - EUROCRYPT 2000, Lecture Notes in Computer Science 1 807, pp. 
156-171, 2000; and P. MacKenzie et al., "Password Authenticated Key Exchange Based on 



RSA," Advances in Cryptology - ASIACRYPT 2000, pp. 599-613, 2000, the disclosures of 
which are incorporated hy reference herein. 

Since the device stores at most only public information, its capture is of no consequence. 
On the other hand, in all of these protocols, the server either knows the user's password or else 
5 can mount an offline dictionary attack against it. 

More importantly, when these protocols are used for the retrieval of a private key from 
the server, the private key (which would most likely be encrypted with the password) would be 
exposed to the server after a successful offline dictionary attack on the password. 

Other existing approaches resort to multiple servers and require that, at most, some 
10 threshold number of these servers cooperate in a dictionary attack, see, e.g., the above-referenced 
W. Ford et al. approach. But this means that some server must be trusted. Also, such existing 
□ approaches do not address the possibility that an attacker already knows the user's password or 
3 guesses it quickly. Once the attacker guesses the password and downloads the private key, the 

attacker can use it for an unlimited time. 
J 1 5 Still another existing approach to such a cryptographic security problem is to ensure that 

the private key cannot be used to sign messages dated before the device was captured. This is 
achieved by "forward secure" signature schemes, which intuitively change the private key (but 

3 not the public key) over time so that the captured private key can be used to sign messages only 

4 dated in the future, see, e.g., M. Bellare et al., 'A Forward-secure Digital Signature Scheme," 
U 20 Advances in Cryptology - CRYPTO '99, Lecture Notes in Computer Science 1666, pp. 43 1-438, 

1999; and H. Krawczyk, "Simple Forward-secure Signatures From Any Signature 
Scheme,"ACM Conference on Computer and Communication Security, pp. 1 08-1 15, Nov. 2000, 
the disclosures of which are incorporated by reference herein. However, such an approach does 
not prevent any future signatures by the attacker once the device is captured, but rather permits 

25 them in a limited way. 

If the device can sense that its private key is about to be discovered, as might be possible 
if the device is a coprocessor with tamper detection circuitry, then another alternative is for the 
device to change the private key when it detects a pending compromise so that future signatures 
subliminally disclose to an authority receiving those signatures that the device has been 

30 compromised, see, e.g., J. Hastad et al., "Funkspiel Schemes: An Alternative to Conventional 
Tamper Resistance," ACM Conference on Computer and Communications Security, pp. 
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125-133, Nov. 2000, the disclosure of which is incorporated by reference herein. However, such 
an approach also does not prevent any future signatures by the attacker once the device is 
captured, but rather permits them in a way that subliminally alerts an authority. 

Yet other existing approaches employ "server aided protocols," whereby the 
5 computational burden of a secret cryptographic computation is moved from the device to a more 
powerful server. Some of these protocols place trust in the server and thus expose the device's 
private information to the server, see, e.g., N. Asokan et al., "Server- Supported Signatures," 
Journal of Computer Security 5(1), 1997; and D. Dean et al., "Cryptography as a Network 
Service," 2001 ISOC Symposium on Network and Distributed System Security, Feb. 2001, the 

10 disclosures of which are incorporated by reference herein. While others of these protocols 
attempt to hide the private key from the server but nevertheless have the server do the bulk of 
the computation, see, e.g., T. Matsumoto et al., "Speeding up Computation with Insecure 
Auxiliary Devices,"Advances in Cryptology - CRYPTO '88, Lecture Notes in Computer Science 
403, pp. 497-506, 1989; P. Beguin et al., "Fast Server- Aided RSA Signatures Secure Against 

15 Active Attacks," Advances in Cryptology - CRYPTO '95, Lecture Notes in Computer Science 
963, pp. 57-69, 1995; and S. Hong et al., "A New Approach to Server-aided Secret 
Computation," 1 st International Conference on Information Security and Cryptology, pp. 33-45, 
1998, the disclosures of which are incorporated by reference herein. 

However, such server aided protocols attempt to reduce the computation required of the 

20 user's device rather than attempting to render the device impervious to an offline dictionary 
attack once captured. 

Thus, there exists a need for techniques which overcome drawbacks associated with 
existing cryptographic approaches and which thereby make networked cryptographic devices 
more resilient to capture. 

25 Summary of the Invention 

The present invention provides techniques by which a device that performs private key 
operations (e.g., signatures or decryptions) in networked applications, and whose local private 
key is activated with, for example, a password or personal identification number (PIN), can be 
immunized to offline dictionary attacks in case the device is captured. The techniques do not 
30 assume tamper-resistance of the device, but rather exploit the networked nature of the device, in 



that the device's private key operations are performed using a simple interaction with a remote 
server. This server, however, is untrusted, i.e., its compromise does not reduce the security of 
the device' s private key unless the device is also captured, and need not have a prior relationship 
(e.g., pre-registration process) with the device. 
5 For instance, in one aspect of the invention, a technique for use in a device associated 

with a first party (e.g., client device) for performing a key retrieval operation comprises the 
following steps. The first party device generates a request for the partial assistance of a device 
associated with a second party (e.g., server) in recovering a key from data stored on the first party 
device. The second party device is remote from the first party device. The request is transmitted 
1 0 from the first party device to the second party device. Then, the first party device receives results 
generated by the second party device based on the partial assistance provided by the second party 
Q device. At least a portion of the received results are used in the first party device to recover the 
"*= key for subsequent use as a private key in one or more associated public key cryptographic 
w techniques (e.g., decryption or signature operations). 

d\5 The key may have a piece of secret information (e.g., password, PIN) associated 

therewith which is included in the request. The partial assistance may be provided by the second 
3 party device when a verification is made by the second party device, based on the piece of secret 
□ information, that the first party sent the request. 

5 Further, the request generated by the first party device may comprise cryptographic 

U 20 information included in the data stored on the first party device and previously generated from 
the key. This cryptographic information is referred to herein as a "ticket." The cryptographic 
information or ticket may be generated via an encryption operation which is a function of one 
or more pieces of secret information (e.g., password, PIN) associated with the first party, the key, 
and a public key associated with the second party device. 
25 .Still further, the results generated by the second party device may comprise results 

associated with the second party device partially decrypting at least a portion of the 
cryptographic information or ticket in the request. Then, the step of using at least a portion of 
the received results in the first party device may further comprise completing the decryption of 
at least a portion of the cryptographic information to recover the key. The first party device may 
30 at least temporarily store or cache the recovered key. 
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The inventive techniques are further extended with support for key disabling, by which 
the rightful owner of a stolen device can disable the device's private key even if the attacker 
already knows the user's password. 

For instance, in another aspect of the invention, a technique for use in a device associated 
5 with a first party (e.g. , client device) for performing a private key operation associated with one 
or more public key cryptographic techniques comprises the following steps. The first party 
device generates a request for the partial assistance of a device associated with a second party 
(e.g., server) in performing aprivate key operation using a private key associated with data stored 
on the first party device. The second party device is remote from the first party device. The 
1 0 request is transmitted from the first party device to the second party device. Then, the first party 
device receives results generated by the second party device based on the partial assistance 
provided by the second party device. At least a portion of the received results are used in the first 
party device to perform the private key operation. 

Then, in order to disable the private key operation, the first party device (or some other 
15 party or entity, or the first party from some other device) may then request the second party 
device to ignore a subsequent request to perform partial assistance for a private key operation. 
The request to ignore subsequent requests may be authenticated by the second party device. 

The data stored on the first party device may have a piece of secret information (e.g., 
password, PIN) associated therewith, which is included in the request. Then, the partial 
20 assistance may be provided by the second party device when a verification is made by the second 
party device, based on the piece of secret information, that the first party sent the request. 

Further, the step of sharing the performance of the private key operation may comprise 
a function sharing operation. The data stored on the first party device may have been constructed 
by generating a first share and a second share of a private key associated with the first party 
25 device. 

Still further, the data stored on the first party device may comprise an encryption of at 
least the second share of the private key in accordance with a public key associated with the 
second party device so as to generate cryptographic information (or ticket). The request 
generated in the first party device may comprise the cryptographic information. 
30 Additionally, the step of using at least a portion of the received results in the first party 

device to perform the private key operation may comprise completing a computation of the 
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private key operation at the first party device using results of a computation portion contributed 
by the second party device. 

It is to be understood that while the private key operation may comprise many types of 
decryption operations, it may preferably comprise an ElGamal' protocol. Similarly, while the 
5 private key operation may comprise many types of signature operations, it may preferably 
comprise an RSA protocol. 

These and other objects, features and advantages of the present invention will become 
apparent from the following detailed description of illustrative embodiments thereof, which is 
to be read in connection with the accompanying drawings. 

10 Brief Description of the Drawings 

FIG. 1 is a flow diagram illustrating a key retrieval protocol in accordance with an 
embodiment of the present invention; 

FIG. 2 is a flow diagram illustrating a protocol with key disabling in accordance with a 
first embodiment of the present invention; 
15 FIG. 3 is a flow diagram illustrating a protocol with key disabling in accordance with a 

second embodiment of the present invention; and 

FIG. 4 is a block diagram illustrating a generalized hardware architecture of a data 
network and computer systems suitable for implementing one or more of the methodologies 
according to the present invention. 

20 Detailed Description of Preferred Embodiments 

The present invention provides techniques to render the private key of a networked device 
invulnerable to offline dictionary attacks, even if the device is captured. The techniques exploit 
the fact that the device has network connectivity at the time it is required to perform a private key 
operation, and thus can interact with a remote party (e.g., remote server) at that time to complete 
25 the operation. This is characteristic of virtually any device involved in an interactive 
authentication or key exchange protocol. 

By way of example and without limitation, it is to be understood that a "device" may 
include any type of computing system that may be employed in a networked environment, e.g., 
a personal computer (including desktops and laptops), a personal digital assistant (PDA), a 



smartcard, a cellular phone, etc. Likewise, by way of example and without limitation, a "server" 
may also be any type of computing system that may be employed in a networked environment. 
Thus, it is to be understood that the protocols of the invention may be implemented between any 
two parties or entities. 

5 The present invention preferably exploits network connectivity by employing a remote 

server that assists the device in performing its private key operation. This remote server need 
not have any preexisting relationship with, or knowledge of, the device (though the device needs 
a public key for the server). Moreover, the server is untrusted. That is, the server, even if it 
misbehaves, gains no information that would help it to compute signatures that verify with the 

10 device's public key or to decrypt messages encrypted under the device's public key. The only 
behavior that is preferred of the server is that it executes the correct protocol to respond to a 
well-formed request, and that it stop responding to invocations pertaining to a device's public 
key (e.g., for a period of time) after it has received sufficiently many malformed requests 
associated with this public key. This latter behavior is preferred in order to prevent an "online" 

15 dictionary attack against the password. We note, however, that this feature does not present a 
denial-of-service vulnerability, since in the protocols of the invention, an attacker can conduct 
an online dictionary attack only after it has captured the device, thus, use of the device by the 
legitimate user is presumably already denied. 

The present invention provides two types of protocols that achieve the above properties. 

20 These types functionally differ on whether they enable the device's private key to be disabled. 
If the device is stolen, it is natural for the device's rightful owner to wish to disable the use of 
the private key, to account for the possibility that the attacker already knows the user' s password 
(e.g., by observing the user type it) or can guess it in very few tries (e.g., due to his intimate 
knowledge of the user). 

25 In the key disabling type of protocol of the invention, the user can issue a request to the 

server to disable future use of the private key associated with the device's public key. Once the 
server receives this request and verifies it is well-formed, the device's key is rendered useless to 
the attacker, even if the attacker knows the user's password. The attacker will thus be unable to 
employ the key in future interactive protocols or to decrypt future encrypted messages. This 

30 feature is especially useful if revocation of the device' s public key via a public key infrastructure 



(e.g., a certificate revocation list) has an associated delay (if it exists at all). In contrast, using 
the protocols of the invention advantageously permits the private key to be disabled immediately. 

Advantageously, protocols of the invention that do not provide key disabling are 
compatible with any public key cryptosystem or signature scheme in use by the device, and any 
5 protocol using them. Protocols of the invention supporting key disabling depend on the type of 
private key operations in use. 

The present invention presumes a system with a device (referred to as "dvc") and a server 
(referred to as "svr") that communicate by exchanging messages over a public network. An 
example of such an arrangement will be described below in the context of FIG. 4. In the 
10 protocols of the invention, the device is used either for generating signatures or decrypting 
messages (i.e., private key operations), and does so by interacting with the server. The signature 
D or decryption operation is password-protected, by a password n 0 . The system is initialized with 

Zj public data, secret data for the device, secret data for the user of the device (i.e., 7t 0 ), and secret 

data for the server. The public and secret data associated with the server may simply be a 
yj 15 certified public key and associated private key, respectively, which is set up well before the 
device is initialized. 

The device-server protocols of the invention allow a device operated by a legitimate user 
Q (i.e., one who knows tc 0 ) to sign or decrypt a message with respect to the public key of the 

,.Z device, after communicating with the server. In those protocols supporting key disabling, device 

20 initialization may create additional secret data that, if sent to the server, will cause the server to 
no longer execute the decryption or signing protocol with that device. 

Each adversary considered is presumed to control the network; i.e., the attacker controls 
any inputs to dvc or svr, and observes their outputs. Moreover, an adversary can "capture" 
certain resources. The possible resources that may be captured by the attacker are dvc, svr, and 
25 tz 0 . Once captured, the entire static contents of the resource become known to the attacker. The 
one restriction on the adversary is that if he captures dvc, then he does so after dvc initialization 
and while dvc is in an inactive state, i.e., dvc is not presently executing the protocol with tz 0 as 
input, and that 7t 0 is not subsequently input to the device by the user. This decouples the capture 
of dvc and n 0 , and is consistent with a motivation that dvc is captured while not in use by the 
30 user and, once captured, is unavailable to the user. 
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We denote by Adv(S), where S c {dvc, svr, 7i 0 } the class of adversaries who succeed in 
capturing the elements of S. As such, Adv(5,) c Adv(S 2 ) ifS l c S 2 . Thus, some security goals 
of the inventive protocols may be informally stated as follows: 

I. Any adversary in Adv ({svr, tz 0 }) is unable to forge signatures or decrypt messages for 
the device (with overwhelming probability). 

II. Any adversary in Adv ({dvc}) can forge signatures or decrypt messages for the device 
with probability at most q/\A\ after q invocations of the server, where A is the space from 
which the user's password is drawn (uniformly at random). 

III. Any adversary in Adv ({dvc, svr}) can forge signatures or decrypt messages for the 
device only if it succeeds in an offline dictionary attack on the user's password. 

IV. Any adversary in Adv ({dvc, iz 0 }) can forge signatures or decrypt messages for the 
device only until the device key is disabled (in those schemes supporting key disabling), 
and subsequently cannot forge signatures or decrypt messages for the device. 

Before explaining the protocols of the invention, we first introduce some definitions and 
notations which will be used in accordance with their explanations. 

Security parameters. Let k be the main cryptographic security parameter; a reasonable 
value today may be k =1 60. We will use X > k as a secondary security parameter for public keys. 
For instance, in an RS A public key scheme, we may set X = 1 024 to indicate that we use 1 024-bit 
moduli. 

Hash functions. We use h, with an additional subscript as needed, to denote a hash 
function. Unless otherwise stated, the range of a hash function is {0, 1} K . It is generally 
preferred that these hash functions behave like random oracles, see, e.g., M. Bellare et al., 
"Random Oracles Are Practical: A Paradigm for Designing Efficient Protocols," ACM 
Conference on Computer and Communications Security, pp. 62-73, Nov. 1993, the disclosure 
of which is incorporated by reference herein. However, hash functions with weaker properties 
may be employed. 

Keyed hash functions. A keyed hash function family is a family of hash functions {f v } 
parameterized by a secret value v. We will typically write f(m) as/(v, m). We also use a specific 
type of keyed hash function, a message authentication code (MAC). We denote a MAC family 
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as {macj . We do not require MACs to behave like random oracles, but to have the following 
standard property: if a is unknown, then given zero or more pairs <m l , mac^m,) >, it is 
computationally infeasible to compute any pair <m, mac Jm) > for any new m * m t . 

Encryption schemes. An encryption scheme e is a triple (G enc , E, D) of algorithms, the 
5 first two being probabilistic, and all running in expected polynomial time. G enc takes as input 1 x 
and outputs a public key pair (pk, sk), i.e., (pk, sk) - G e „ c (l x ). E takes a public key pk and a 
message m as input and outputs an encryption c for m; we denote this c *- E pk (m). D takes a 
ciphertext c and a secret key sk as input and returns either a message m such that c is a valid 
encryption of m, if such an m exists, and otherwise returns ±. 
10 It is preferred that an encryption scheme be secure against adaptive chosen ciphertext 

attacks, see, e.g., C. Rackoff et al., "Non-interactive Zero-knowledge Proof of Knowledge and 
O Chosen Ciphertext Attack," Advances in Cryptology - CRYPTO '91, pp. 433-444, 1991, the 
%j disclosure of which is incorporated by reference herein. Other examples can be found in M. 
; = Bellare et al., "Optimal Asymmetric Encryption," Advances in Cryptology - EUROCRYPT '94, 
Ly 15 Lecture Notes in Computer Science 950, pp. 92-1 11, 1995; and R. Cramer et al., "A Practical 
[ Public Key Cryptosystem Provably Secure Against Adaptive Chosen Ciphertext Attack," 
;- I Advances in Cryptology - CRYPTO '98, Lecture Notes in Computer Science 1462, pp. 13-25, 
p 1998, the disclosures of which are incorporated by reference herein. 

A Signature schemes. A digital signature scheme S is a triple (G sig , S, V) of algorithms, the 

>■ W 20 first two being probabilistic, and all running in expected polynomial time. G sig takes as input 1 x 
and outputs a public key pair (pk, sk), i.e., (pk, sk) - G slg (1 A ). S takes a message m and a secret 
key sk as input and outputs a signature a for m, i.e., o - S sk (m). V takes a message m, a public 
key pk, and a candidate signature a' for m as input and returns the bit b = 1 if a' is a valid 
signature for m, and otherwise returns the bit b = 0. That is, b - V pk (m,a'). Naturally, if a - 
25 S sk (m),thenV pk (m,a) = l. 

We say a signature scheme is "matchable" if for each public key pk produced by G slg (l x ) 
there is a single secret key sk that would be produced (i.e., the probability of (pk, sk) ^G stg (l x ) 
and (pk, sk") «- G slg (l x ) with sk * sk' is zero), and there is a probabilistic algorithm M that runs in 
expected polynomial time and that takes as input a public key pk and a secret key sk, and returns 
30 1 if sk is the single private key corresponding to pk (i.e., if G sig (l x ) could have produced (pk, sk) 
with non-zero probability) and returns 0 otherwise. In existing signature schemes with which 
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the invention may be employed, implementation of the M function is well-known and 
straightforward. "Matchable" encryption schemes are defined similarly. 



1. Protocol Without Key Disabling 

The key retrieval protocol of the invention achieves goals I, II, and III described above. 
5 Since this protocol remains the same regardless of whether the device is used to decrypt or sign, 
herein below we discuss the protocol using terminology as if the device is used for signing. This 
scheme is parameterized by the device's signature scheme S and an encryption scheme e for the 
server (when speaking about security of this and later protocols against offline dictionary attack, 
we also include a parameter A to denote a dictionary of the possible passwords), and works 

s 1 0 independently of the form of S and e. We thus also refer to this key retrieval protocol herein as 

J "generic," i.e., the generic protocol. 

At device initialization time, the private key of the device is encrypted in a way that can 
be recovered only with the cooperation of both the device (if it is given the user's password) and 
the server. This ciphertext, called a "ticket," also embeds other information that enables the 

1 5 server to authenticate requests that accompany the ticket as coming from a device that has been 

■ given the user's password. When the device is required to perform an operation with its private 
key, it sends the ticket to the server. The device accompanies the ticket with evidence of its 
knowledge of the user's password. The server can check this evidence against information in the 
ticket. The server then performs a transformation on the ticket to "partially decrypt" it, and 

20 returns the result to the device. The device completes the decryption to recover its private key. 
The device may then use the private key for performing the required operations, and may even 
cache the key in volatile memory for some period of time so that additional operations can be 
performed without contacting the server for each one. 

If an attacker captures the device and guesses the user's password (i.e., the adversary is 

25 in Adv ( {dvc, iz 0 } )), then it can retrieve the private key and keep it forever. Limiting the damage 
an attacker can do in this case requires assistance from some external mechanism for revoking 
the device's public key, if such a mechanism exists. 

In the following two subsections, details of the steps of the initialization algorithm and 
the key retrieval protocol (or generic protocol) are provided. 
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1.1 Device Initialization 

The inputs to device initialization are the server's public encryption key pk sw , the user's 
password tc 0 , the device's public signature verification key pk dw , and the corresponding private 
signing key sk dvc . The steps of the initialization algorithm proceed as follows, where "z - R S" 
5 is used to denote assignment to z of an element of S selected uniformly at random: 



Lu The symbol <- generally refers to an assignment of the computation results of the right 

hand side of the expression to the value or parameter of the left hand side of the expression. The 
m operator © represents the exclusive-OR (XOR) operation. The values v, a, x,pk dvc , and pk svr are 
jrtlO saved in stable storage on the device. All other values, including sk d<JC , tz 0 , b and c, are deleted 
P from the device. It is assumed that/outputs a value of length equal to the length of s& dvc . For 

the generic protocol, it is assumed this length is X. 

The value x is the previously referred to "ticket." Note that this ticket encapsulates a 

value c from which the device can recover sk dvc with knowledge of the user's password. The 
1 5 server's role in the key retrieval protocol thus involves decrypting this ticket and sending c to the 

device (encrypted). Note that c does not provide the basis for the server to mount an attack 

against sk dvc , since the server does not know v. 

1.2 Key Retrieval Protocol 

20 Referring now to FIG. 1 , a flow diagram illustrates the steps of a key retrieval (or generic) 

protocol 100 according to an embodiment of the present invention. In accordance with FIG. 1, 
steps shown on the left side of the figure are performed by the device (dvc), and steps shown on 



v<-*{0,l}* 

*<-*{o,i}* 

b<r- h{x 0 ] 
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the right side of the figure are performed by the remote server (svr). The arrows passing between 
the device and server represent communication between them. 

The input provided to the device to initiate the key retrieval protocol is the input 
password n and all of the values saved on stable storage in the initialization protocol described 
5 above in subsection 1.1. It is to be understood that we denote tt; 0 as the actual user' s password, 
and % as the password input to the protocol (which may be different, especially if the attacker 
is trying to run the protocol). The protocol by which the device retrieves sk ds/c is thus depicted 
in FIG. 1. 

In step 102, the device computes J3, which is an authenticator that proves knowledge of 
10 7i to the server. As previously explained, h represents an appropriate hash function. In step 1 04, 
the device computes p, which acts as a one-time pad by which the server encrypts c to return it 

□ to the device. In step 1 06, the device computes y, which is an encryption (using the public key 
of the server) of /?and p to securely transport them to the server. 

In step 108, the device computes the value 8 as a function of y and x, which is a message 
Ail 5 authentication code that is generated from the MAC key a stored on the device, and that the 
server uses to confirm that this request actually originated from the device. 

Though 8 is not required to prove security of this protocol, it nevertheless is important 

□ in practice since it enables the server to distinguish requests bearing x but not originating from 
the device (i.e., mac a (<y, x>) * 8), from requests bearing x that originate from the device but 

- 20 for which the device's knowledge of the user's password cannot be verified (i.e., /? *■ b). The 
latter category may indicate an online dictionary attack, and accordingly the ticket x should be 
ignored (e.g., for some period of time) after sufficiently many such requests. The former type 
should not "count against" x, however, since they do not pose a risk to the password; indeed, the 
authenticator /?is never checked in these cases. On the contrary, if this former category were 
25 treated like the latter, then this would enable a denial-of-service attack on x (i.e., the device) in 
which an attacker, having seen t pass on the network, submits requests to the server containing 
x and random values for y and 8. 

Next, in step 110, the device transmits the values y, 8 and x to the server. 
Upon receipt of these values, the server decrypts the ticket x in order to recover values 
30 a, b and c, in step 1 12. In step 1 14, the server uses y, 8 and x to confirm that this request for a 
private key actually originated from the device. Thus, if mac Q (<y, x>) * 8, then the server aborts 
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the private key retrieval operation. In step 116, the server decrypts y in order to recover values 
/? and p. In step 118, the server determines whether it is in receipt of a request that bears x and 
originated from the device but that is a request for which the device's knowledge of the user's 
password cannot be verified. Thus, if P * b, then the server aborts the private key retrieval 
5 operation. 

Assuming the operation is not terminated in step 1 14 or 1 16, the server then computes 
parameter 7] by performing an exclusive-OR operation between p and c, in step 120. Thus, in 

effect through steps 112 through 120, the server performs a transformation on the ticket to 
"partially decrypt" the ticket. In step 122, the server transmits the result tj to the device. 
10 In step 124, the device computes its private key sk by performing exclusive-OR 

operations between p, rj and/(v, n ). Thus, in effect through step 124, the device completes the 

1 decryption to recover its private key. In step 1 26, the device determines whether its public key 

| and its computed private key are matched, as explained above. Thus, if M (pk dvc , sk)^ 1, then 
the key retrieval operation is aborted. Assuming the key pair is matched, the protocol 1 00 returns 

' 1 5 (outputs) sk as the device's private key, in step 128. The device may then use the private key for 
performing the required operations (e.g., signing and decrypting). 

It is important for security that the device delete /?, p and, of course, sk when it is done 

i with them, so that none of these values are available to an attacker who subsequently captures 
the device. In particular, these values are preferably never stored on stable storage on the device 

20 to ensure, e.g., that they will disappear from the device if the device crashes. However, the 
device may cache the private key skin volatile memory for some period of time so that additional 
operations can be performed without contacting the server for each additional operation. 

Brief intuition for the security of this protocol is as follows. First, goal I is achieved due 
to the encryption of sk dvc by fly, tz 0 ), since an adversary in Adv ({svr, 7i 0 }) does not know v. 

25 Goal II is achieved since the only way an adversary in Adv ( {dvc} ) gains information about the 
password is by submitting guesses at j3 (or rather, /?s resulting from guesses at the password) 
to the server. Finally, even an adversary in Adv ({dvc, svr}) is required to conduct an offline 
dictionary attack against the password to discover sk dvc , since sk dvc is encrypted using fly, 7i 0 ). 
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2. Protocols With Key Disabling 

In this section, protocols of the invention which support key disabling are explained. It 
is to be appreciated that such protocols satisfy all of the goals (I-IV) described above, including 
the ability for the user to disable the private key of the device even after the attacker has captured 
5 the device and guessed the user's password. As is evident, the reason that key disabling is not 
implemented in the generic protocol, described above in section 1 , is that the device' s private key 
is recovered by the device as part of that protocol. As a result, an attacker who captures the 
device and guesses the user's password can recover the private key and use it indefinitely. 

In order to make key disabling possible, the present invention provides protocols in which 

10 the private key is never recovered by the device. Rather, the device performs each signature or 
decryption operation individually by interacting with the server. This is achieved by 2-out-of-2 
function sharing, where the function being shared is the device's signature or decryption 
function. More precisely, when the device is initialized, two "shares" of the device's private key 
are generated. The first share is constructed so that it can be generated from the user's password 

1 5 and information stored on the device. The second share, plus other data for authenticating 
requests from the device, are encrypted under pk sw to form the device's ticket. Both shares are 
then deleted from the device. In the device's signature or decryption protocol, the device sends 
its ticket plus evidence that it was given the user's password, the server verifies this using 
information in the ticket, and then the server contributes its portion of the computation using its 

20 share. Together with the device's contribution using its share (generated from the user's 
password), the signature or decryption can be formed. 

Disabling the private key sk dvc is achieved by requesting that the server permanently 
ignore the device's ticket. Once this is done, further queries by the attacker - specifically, any 
adversary in Adv ({dvc, ir 0 }) - will not yield further signatures or decryptions. Of course, to 

25 prevent a denial-of-service attack against the device even without it being stolen, requests to 
disable the device's ticket must be authenticated. The protocols of the invention provide this 
feature as well. It can be proven that the protocols of the invention meet all of the above- 
mentioned goals in the random oracle model. 

The feature of key disabling generally depends on the particular decryption/signature 

30 protocol in which it is implemented. For example, in the signature protocol illustrated herein for 
the RSA signature protocol, the server learns the message m being signed. It is therefore 
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important that m be public information if the server is untrusted. This requirement is consistent 
with signatures in TLS 1.0 (see, e.g., T. Dierks et al., "The TLS Protocol Version 1.0," IETF 
Request for Comments 2246, Jan. 1999, the disclosure of which is incorporated by reference 
herein), for example, since in that protocol, parties sign only public information. Second, due 
5 to the use of function sharing in the protocols of the invention, they are generally dependent on 
the particular signature or decryption algorithm in use. In the following subsections, we describe 
protocols for RSA signatures and ElGamal decryption, though the techniques of the invention 
generalize to many other signature and decryption schemes, e.g., RSA decryption protocol, 
Schnorr signature protocol, DSA protocol (in which case there is more than one request/answer 
10 exchange between dvc and svr, e.g., request 1 /answer l/request2/answer2), etc. 

2.1 S-RSA: A Protocol for RSA Signatures 

In this subsection, it is presumed that the device signs using a standard encode-then-sign 
RSA signature algorithm (e.g., "hash-and-sign" as described in D. E. Denning, "Digital 
Signatures with RSA and Other Public-key Cryptosystems," Communications of the ACM 
15 27(4):388-392, Apr. 1984, the disclosure of which is incorporated by reference herein) as 
described below. 

Accordingly, we refer to this protocol as S-RSA. The public key of the device is pk^ z 
= <e,N> and the secret key is sk^ = <d, N, <$> (N)>, where ed = ^ (N) \,N is the product of two 
large prime numbers, and 4> is the Euler totient function. The notation = ^ means equivalence 
20 modulo <j) (N). The device's signature on a message m is defined as follows, where 'encode' is 
the encoding function associated with S, and K slg denotes the number of random bits used in the 
encoding function (e.g., K slg = 0 for a deterministic encoding function): 



s<r- (encode(m,r)) d mod N 
return < s,r> 
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Here, the signature is o = <s, f>, though it may not be necessary to include r if it can be 
determined from m and s. We remark that "hash-and-sign" is an example of this type of 
signature in which the encoding function is simply a deterministic hash of m, and that PSS (as 
described in M. Bellare et al., "The Exact Security of Digital Signatures ~ How to Sign with 
5 RSA and Rabin, Advances in Cryptology - EUROCRYPT '96, Lecture Notes in Computer 
Science 1070, pp. 399 - 416, 1996, the disclosure of which is incorporated by reference herein) 
is another example of this type of signature with a probabilistic encoding. 

Both of these types of signatures were proven secure against adaptive chosen message 
attacks in the random oracle model. Naturally any signature of this form can be verified by 
10 checking that s e = N encode (m, r). In the function sharing primitive used in the inventive 
protocol, d is broken into shares d x and d 2 such that d x + d 2 = ^ d. 

2.1.1 Device Initialization 

The inputs to device initialization are the server's public encryption key pk svn the user's 
password 7t 0 , the device's public key pk dvc = <e,N>, and the corresponding private key sk dvc = 
15 <d,N, (j)(7V) >. The initialization algorithm proceeds as follows: 



□ 



h dsU (t) 
v^{0,l} K 




d 2 <r- d- d x mod fy(N) 
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Here, we assume that/outputs an element of {0, 1} X+K . The values t, v, a, x,pk dyc , and 
pk svr are saved on stable storage in the device. All other values, including u, b, d, d x , d 2 , §(N), 
and it 0 , are deleted from the device. The values t and x should be backed up offline for use in 
disabling if the need arises. The value x is the device's "ticket" that it uses to access the server. 

5 2.1.2 Signature Protocol 

This subsection illustratively explains the protocol by which the device signs a message 
m in accordance with the invention. The input provided to the device for this protocol is the 
input password it, the message m, and all of the values saved on stable storage in the 
initialization protocol of subsection 2.1.1. 

1 0 Referring now to FIG. 2, a flow diagram illustrates a protocol 200 with key disabling in 

accordance with a first embodiment of the present invention, i.e., the S-RSA protocol. In step 
202, the device computes /?, which is a value that proves the device's knowledge of it to the 
server. The device computes pin step 204, which is a one-time pad by which the server encrypts 
v to return it to the device. The value r is a K j;g -bit value used in the 'encode' function and is 

1 5 computed in step 206. The value y is computed in step 208 and represents an encryption of m, 
r, /?and pin order to securely transport them to the server. 

In step 210, 5 is computed by the device and represents a message authentication code 
computed using a. This value shows the server that this request originated from the device. As 
in section 1 above, 6 is not necessary to prove security relative to the above-mentioned goals, but 

20 nevertheless is important in practice to prevent denial-of-service attacks. It is important that the 
device delete p, d u and /?when the protocol completes, and to never store them on stable storage. 
Next, in step 212, the device transmits the values y, 6 and x to the server. 
Upon receipt of these values, the server decrypts the ticket x in order to recover values 
a, b and u, d 2 and N in step 214. In step 216, the server uses y, 6 and x to confirm that this 

25 request for a private key actually originated from the device. Thus, if mac a (<y, t>) * 8, then 
the server aborts the private key retrieval operation. In step 218, the server decrypts y in order 
to recover values m, r, /?and p. In step 220, the server determines whether it is in receipt of a 
request that bears t and originated from the device but that is a request for which the device's 
knowledge of the user's password cannot be verified. Thus, iif$*b, then the server aborts the 

30 private key retrieval operation. 
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Assuming the operation is not terminated in step 2 1 6 or 220, the server computes v in step 
222 using the 'encode' function m, r, d 2 (the server's share of d) and N. In step 224, the server 
then computes parameter T] by performing an exclusive-OR operation between p and v. In step 
226, the server transmits the result rj to the device. 
5 In step 228, the device computes parameter v by performing an exclusive-OR 

operation between p and rj . The device computes d x (its share of J) in step 230 as f(y, 71 ). In 
step 232, the device computes the signature s using the 'encode' function m, r, d x and N. The 
signature is verified in step 234, and returned (outputted) in step 236. 

Suppose that the device has been stolen, and that the user wishes to permanently disable 
10 the private key of the device. Provided that the user backed up t and t before the device was 
Q stolen, the user can send t, t to the server. Upon recovering <a, b, u, d 2 , N> *- D sk ^{r) , the 

%J server verifies that u = h dsbi (t) and, if so, records x on a disabled list. Subsequently, the server 
J Z. should refuse to respond to any request containing the ticket x . This requires that the server store 

t (or a hash of it) on a "blacklist." Rather than storing x forever, though, the server can discard 
s 1 5 t once there is no danger that pk dvc will be used subsequently (e.g., once the public key has been 
S-1 revoked). Note that for security against denial-of-service attacks (an adversary attempting to 

disable r without t), /z dsb , need not be a random oracle, but simply a one-way hash function. 
Q The intuition behind the security of this protocol is similar to that for the generic protocol. 

■ y The major difference, however, is that only the server's contribution v to the signature of m is 
20 returned to the device, not sk dvc (or the server's share of it). This is what makes key disabling 

possible. 

The efficiency of the S-RSA protocol may generally be worse than the signing efficiency 
of the underlying RSA signature scheme, not only because of the message and encryption costs, 
but also because certain optimizations (e.g., Chinese remaindering) that are typically applied for 
25 RSA signatures cannot be applied in S-RSA. Nevertheless, since dvc can compute (encode 
(m,r)Y 1 mod N while awaiting a response from svr, a significant portion of the device's 
computation can be parallelized with the server's computation. 
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2.2 D-ElG: A Protocol for ElGamal Decryption 

In this subsection, aprotocol of the invention by which the device can perform decryption 
with an ElGamal (as described in T. ElGamal, "A Public Key Cryptosystem and a Signature 
Scheme Based on Discrete Logarithms," IEEE Transactions on Information Theory, 3 1 :469-472, 
1985, the disclosure of which is incorporated by reference herein) private key, using the 
techniques described herein to gain the same benefits as S-RSA signatures yielded for RSA 
signatures. The focus here is on decryption (versus signatures), and ElGamal (versus RSA), to 
demonstrate the breadth of cryptographic operations to which the inventive techniques apply. 

For ElGamal encryption, the public and private keys of the device are pk^ c = <g,p,q,y> 
and sk dvc = <g, p, q, x>, respectively, where p is an A-bit prime, g is an element of order q in 
Z*, x is an element of Z q chosen uniformly at random, and j; = g* mod p. For generality, we 

describe the D-elG protocol using an abstract specification of "ElGamal- like" encryption. An 
"ElGamal-like" encryption scheme is an encryption scheme in which: (i) the public and private 
keys are as above; and (ii) the decryption function D can be expressed in the following form: 



D <gp q x> (c) : abort if valid(c) = 0 
w<r- select(c) 
z <- w^mod p 
m<r- reveal(z,c) 
return m 



Above, valid(c) tests the well-formedness of the ciphertext c; it returns 1 if well-formed and 0 
otherwise. The expression select(c) returns the argument w that is raised to the x-th power 
modulo p. The expression reveal(z, c) generates the plaintext m using the result z of that 
computation. For example, in original ElGamal encryption, where q =p - 1 and c = <c v c 2 > = 
<g k mod p, my k mod p> for some secret value k e Z q , valid (<c l5 c 2 >) returns 1 if c„ c 2 e Z* and 
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0 otherwise; select (<c l9 c 2 >) returns c x \ and reveal (z, <c l5 c 2 >) returns c 2 z _1 mod p. It is to be 
noted, however, that the private key is not an argument to 'valid,' 'select,' or 'reveal;' rather, the 
private key is used only in computing z. Using this framework, the D-ElG protocol is described 
in the following subsections. 

2.2.1 Device Initialization 

The inputs to device initialization are the server's public encryption key pk sw , the user's 
password x 0 , the device's public key pk 6vc = <g,p, q, y>, and the corresponding private key sk 6vc 
= <g, p, q, x>. The initialization algorithm proceeds as follows: 

M <- ^dsblW 

v^{0,l} K 
6<- h(% 0 ) 

*1 <- /(v,7l 0 ) 

x 2 <- x - Xj mod q 

y 2 <- g* 2 mod p 

T <~ £ P* svr (< a,b,u,g,p,q,x 2 >) 



10 Here, we assume that/outputs an element of {0,1} 2|?I . The values v, a, y 2 , x,pk^ c ,pk^ r 

and t are saved on stable storage in the device. All other values, including u, b, x, x u x 2 , and tc 0 , 
are deleted from the device. The values t and x should be backed up offline for. use in disabling 
if the need arises. The value x is the device's ticket that it uses to access the service. 
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2.2.2 Decryption Protocol 

Referring now to FIG. 3, a flow diagram illustrates a protocol 300 with key disabling in 
accordance with a second embodiment of the present invention, i.e., the D-elG protocol. More 
specifically, FIG. 3 illustrates a protocol by which the device decrypts a ciphertext c generated 
5 using the device' s public key in an ElGamal-like encryption scheme. The input provided to the 
device for this protocol is the input password 7t, the ciphertext c, and all of the values saved on 
stable storage in the initialization protocol of subsection 2.2.1 above. In this protocol, h zkp is 
assumed to return an element of Z q . 

In step 302, the well-formedness of the ciphertext c is tested by the device. If the 
10 function valid(c) returns a zero, the decryption protocol is aborted. If the function valid(c) 
returns a one, the decryption protocol continues on to the next steps. As before, the device 
O computes /3 in step 304, which is a value that proves the device's knowledge of n to the server. 
Cj The device computes p in step 306. As before, /?is a one-time pad by which the server encrypts 
; u . : certain values (in this case, v, e, s) to return them to the device after performing its share of the 
L 15 decryption operations. In step 308, the device computes y, which is an encryption of c, /?, and 
p, to securely transport these values to the server. In step 310, the device also computes value 
y_ 5, which is a message authentication code computed using a, to show the server that this request 
D originated from the device. 

Next, in step 312, the device transmits the values y, 6 and x to the server, 
m 20 Upon receipt of these values, the server decrypts the ticket x in order to recover values 

a, b, u,p, q, g and x 2 in step 314. As before, in step 316, the server uses y, 5 and x to confirm 
that this request for a private key actually originated from the device. Thus, if mac fl (<y, x>) * 
6, then the server aborts the decryption operation. In step 318, the server decrypts y in order to 
recover values c, /?and p. In step 320, the server determines whether it is in receipt of a request 
25 that bears x and originated from the device, but that it is a request for which the device's 
knowledge of the user's password cannot be verified. Thus, \ip*b, then the server aborts the 
decryption operation. 

In step 322, the expression select(c) returns the argument w that is then raised to the x-th 
power modulo p in step 324. The values r and v' are computed by the server in steps 326 and 
30 328, respectively. Then, in step 330, values v, v\g r mod p are hashed using function /z zkp in order 
to generate e. The value s is then computed by the server in step 332. In step 334, the server 
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then computes parameter J] by performing an exclusive-OR operation between p and v, e and s. 
In step 336, the server transmits the result rj to the device. 

In step 338, the device computes values v, e and 5 by performing an exclusive-OR 
operation between p and J] . The device, in step 340 (like step 322 at the server), computes w 
5 using select(c). In step 342, a check is made to confirm that the returned value of e is consistent 
with the hash function A zkp . If it is not, then the decryption operation is aborted. Assuming the 
operation is not terminated, in step 344, the device computes x x as / (v, n ). The value \i is 
computed in step 346 as w* 1 mod p. Then, in step 348, the reveal expression generates the 
plaintext m using v,[i,p and c. 
10 Thus, it is to be understood that the device's decryption function is implemented jointly 

Pi by dvc and svr in accordance with the D-ElG protocol. Moreover, <v, e, s> constitutes a non- 

1=1 interactive zero-knowledge proof from svr (the "prover") to dvc (the "verifier") that svr 

M 

fy constructed its contribution v correctly. 

Decryption via the D-ElG protocol may be somewhat more costly than decryption in the 
■• ;± 15 underlying ElGamal-like encryption scheme. As in S-RSA, it is preferred that dvc compute u 
p while awaiting a response from svr in order to parallelize computation between the two. 

Like S-RSA, the D-ElG protocol also supports key disabling. Assuming that the user 
! ;i backed up t and x before the device was stolen, the user can send /, x to the server. Upon 
ft! recovering <a, b, u, g, p, q, x 2 > - D sk ^ (r), the server verifies that u = A dsbl (0 and, if so, records 

20 x on a disabled list. Subsequently, the server should refuse to respond to any request containing 
the ticket x. This requires the server to store x (or a hash of it) on a "blacklist." Rather than 
storing x forever, though, the server can discard x once there is no danger that pk dvc will be used 
subsequently (e.g., once the public key has been revoked). 

There are several implementations for ElGamal-like encryption schemes that, when used 

25 to instantiate the description of FIG. 3, result in a protocol that provably satisfies the above- 
mentioned goals I - IV. 

The precise senses in which a particular instance can satisfy goal IV will now be 
discussed. The most natural definition of security for key disabling is that an adversary in Adv 
({dvc, 7t 0 )} who is presented with a ciphertext c after the key has been disabled will be unable 
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to decrypt c. A stronger definition for key disabling could require that c remain indecipherable 
even if c were given to the adversary before key disabling occurred, as long as c were not sent 
to svr before disabling. 

If the original ElGamal scheme is secure against indifferent chosen ciphertext attacks, 
then the protocol of FIG. 3 can be proven secure in the former sense when instantiated with 
original ElGamal. There are, however, ElGamal-like encryption schemes that suffice to achieve 
even the latter, stronger security property, such as the following proposal from V. Shoup et al., 
"Securing Threshold Cryptosystems Against Chosen Ciphertext Attack,"Advances in Cryptology 
- EUROCRYPT '98, pp. 1-16, 1998, the disclosure of which is incorporated by reference herein, 
called TDH1. In this scheme, q is a K-bit prime factor ofp - 1. Encryption of a message m 
proceeds as follows: 



'<g,p,i.y> 



{m):k^ R Z q 




c 5 <r- 1+ kc 4 mod q 



The tuple <c ls c 2 , c 3 , c 4 , c 5 > is the ciphertext. Above, h x outputs a value from {0,1} W , and h 2 
outputs an element of the subgroup of Z p generated by g. For example, this can be achieved by 
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Decryption takes the 

valid(c): < c : ,c 2 ,c 3 ,c 4 ,c 5 > <- c 

w l <- g C5 (c 2 ) C * mod p 
g' <- A,(< c x ,c 2 ,w, >) 
w 2<- (g'TfeY* mod/? 
return (c 4 = h zkp (< g',c 3 ,w 2 >)) 
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defining h 2 (z) = (A'(z)) (p " 1)/9 mod for some other hash function h'. 
following form: 



select(c):< c v c 2 ,c 3 ,c 4 ,c 5 > <- c 
return c 2 

reveal(2,c):< c v c 2 ,c 3 ,c 4 ,c 5 > <- c 

return ^(z) © q 



A second proposal from V. Shoup et al., called TDH2, can also be used to instantiate the 
inventive protocol and achieve the stronger version of goal IV. 

Referring now to FIG. 4, a block diagram illustrates a generalized hardware architecture 
of a data network and computer systems suitable for implementing key retrieval, signature and 

1 0 decryption protocols between two entities, a client and a remote server, according to the present 
invention. As shown, the client (e.g., dvc or device as used above in the protocol explanations) 
comprises a computer system 402, while the server (e.g., svr as used above in the protocol 
explanations) comprises a computer system 404. The two computer systems 402 and 404 are 
coupled via a data network 406. The data network may be any data network across which dvc 

15 and svr desire to communicate, e.g., the Internet. However, the invention is not limited to a 
particular type of network. Typically, and as labeled in FIG. 4, dvc is a client machine and svr 
is a server machine. However, this is not required, and dvc and svr are referred to as client and 



server, respectively, only as an example to show the typical case. Thus, it is to be understood 
that the protocols of the present invention are not limited to the case where dvc and svr are client 
and server, respectively, but instead is applicable to any computing devices comprising dvc and 
svr. 

5 As is readily apparent to one of ordinary skill in the art, the server and client may be 

implemented as programmed computers operating under control of computer program code. The 
computer program code is stored in a computer readable medium (e.g., a memory) and the code 
is executed by a processor of the computer system. Given this disclosure of the invention, one 
skilled in the art can readily produce appropriate computer program code in order to implement 
10 the protocols described herein. 

In any case, FIG. 4 generally illustrates an exemplary architecture for each computer 
D system communicating over the network. As shown, the client device comprises I/O devices 
Zj 408-A, processor 41 0- A, and memory 41 2-A. The server system comprises I/O devices 408-B, 
\ * processor 41 0-B, and memory 41 2-B. It should be understood that the term "processor" as used 
yj 1 5 herein is intended to include one or more processing devices, including a central processing unit 
[ (CPU) or other processing circuitry. Also, the term "memory" as used herein is intended to 
y include memory associated with a processor or CPU, such as RAM, ROM, a fixed memory 
□ device (e.g., hard drive), or a removable memory device (e.g., diskette or CDROM). A portion 
? 1 of this memory may serve as "stable storage," as referred to above. In addition, the term "I/O 
; 20 devices" as used herein is intended to include one or more input devices (e.g., keyboard, mouse) 
for inputting data to the processing unit, as well as one or more output devices (e.g., CRT 
display) for providing results associated with the processing unit. Accordingly, software 
instructions or code for performing the protocols/methodologies of the invention, described 
herein, may be stored in one or more of the associated memory devices, e.g., ROM, fixed or 
25 removable memory, and, when ready to be utilized, loaded into RAM and executed by the CPU. 

As explained in detail above, dictionary attacks against password-protected private keys 
are a significant threat if the device holding those keys may be captured. Accordingly, the 
present invention provides protocols/methodologies to render devices invulnerable to such 
attacks. The protocols/methodologies provide for the device to interact with a remote server to 
30 perform its private key operations. Therefore, the protocols/methodologies are well-suited to a 
device that uses its private key in interactive cryptographic protocols (and so necessarily has 



28 MacKenzie 8-8 

network connectivity to reach the server when use of its private key is required). A prime 
example is a device that plays the role of a client in the TLS protocol with client authentication. 
While the device interacts with a remote server, it can be proven that this server poses no threat 
to the device. Specifically, the server gains no significant advantage in forging signatures that 
5 can be verified with the device's public key or decrypting messages encrypted under the device' s 
public key. In particular, the server cannot mount a dictionary attack to expose the device's 
private key. Even if both the device and server are compromised, the attacker must still succeed 
in an offline dictionary attack before signing on behalf of the device. 

In addition to the above properties, the present invention provides 

10 protocols/methodologies that further provide the feature of key disabling. This enables the user 
to disable the device' s private key immediately, even after the device has been captured and even 
if the attacker has guessed the user's password. Once disabled, the device's key is provably 
useless to the attacker (provided that the attacker cannot also compromise the server). Key 
disabling is thus an effective complement to any public key revocation mechanism that might 

15 exist, particularly if there is a delay for revoking public keys. 

Although illustrative embodiments of the present invention have been described herein 
with reference to the accompanying drawings, it is to be understood that the invention is not 
limited to those precise embodiments, and that various other changes and modifications may be 
made by one skilled in the art without departing from the scope or spirit of the invention. 



